Failure 1: test_sync_entity_circular_relations — lost relation row (the important one)

Root cause

The in-memory SQLite URL (sqlite+aiosqlite://) falls back to SQLAlchemy's StaticPool, which hands the same DBAPI connection to every concurrently checked-out session. All concurrent asyncio tasks therefore share one SQLite transaction scope:

• a COMMIT by one session commits every sibling task's half-done statements;
• a ROLLBACK by one session silently destroys every sibling task's executed-but-uncommitted statements.

Rollbacks are routine, not exceptional: the pool's reset-on-return issues a real DBAPI ROLLBACK at every connection checkin. A probe counting DBAPI calls during one sync of the two-file circular-relations scenario measured 40 commits and 41 rollbacks on the shared connection. scoped_session's exception handler is a second rollback source (any per-file error swallowed by _run_bounded).

During _index_changed_files → BatchIndexer.index_files, per-file upserts run concurrently (asyncio.gather bounded by index_entity_max_concurrent). The losing interleaving:

1. task A's session finishes: DBAPI COMMIT (separate aiosqlite roundtrip);
2. task B's add_all_ignore_duplicates executes INSERT INTO relation (B→A, in the gap between A's commit and A's checkin — both are independent await points);
3. task A's connection checkin fires reset-on-return ROLLBACK → B's INSERT is erased;
4. task B "commits" an empty transaction. No error anywhere; sync reports success.

The final sync-level resolve_relations() pass cannot catch this: "pending" means a relation row with to_id IS NULL, and the destroyed INSERT leaves no row at all. Hence len(entity_b.outgoing_relations) == 0. #938 exposed the race by removing the multi-second per-entity embedding work that previously kept the upsert tasks from interleaving tightly. The window is microseconds, which is why it fired once on a loaded 2-core runner and never locally (30 pytest runs + 500 in-process iterations clean).

Production is not affected: file-based SQLite uses per-session pooled connections (isolated transactions, WAL) and Postgres uses NullPool. DatabaseType.MEMORY is only used by the test environment via engine_session_factory — but the unsafe engine configuration is product code in db.py.

Fix

_create_sqlite_engine now gives MEMORY engines a single-connection blocking pool (AsyncAdaptedQueuePool, pool_size=1, max_overflow=0). The lone connection keeps the in-memory database alive for the engine's lifetime (the reason StaticPool was chosen), while the blocking checkout serializes sessions at transaction granularity — restoring the isolation the repositories assume. No sleeps, no retries; nested-session misuse now fails loudly (pool checkout timeout) instead of silently sharing transactions, and one such test (test_delete_entity_with_relations) was un-nested.

Evidence

• New regression test tests/db/test_memory_db_session_isolation.py fails deterministically on StaticPool (relation count 0 after a sibling session rolls back) and passes with the serialized pool.
• Full unit suite green after the change (2946 passed); 200 in-process iterations of the circular-relations sync scenario green.

Failure 2: test_mcp_sse_forces_local — KeyError: 'FORCE_LOCAL' (Python 3.14 leg)

Root cause

The stdio variants of TestMcpCommandRouting invoke bm mcp, whose command body starts a real background auto-update daemon thread before mcp_server.run (the tests only mock run). That thread hits PyPI (5s timeout) and then rewrites config.json (auto_update_last_checked_at) with an in-place truncating Path.write_text. When that write lands while a later test's CLI invocation reads config.json (app callback → CliContainer.create() → load_config()), the reader sees empty/partial JSON and load_config() raises SystemExit. CliRunner.invoke swallows it, the mocked mcp_server.run never executes, and the test fails with KeyError: 'FORCE_LOCAL' — exactly the CI shape. Nothing is 3.14-specific; the leg only shifted timing (the test also never inspected result, discarding the evidence).

The torn write is also a real production race: the MCP stdio server re-reads config.json on mtime change and exits the process on invalid JSON if it races a CLI save.

Fix

• save_basic_memory_config writes a per-process/per-thread sibling temp file and publishes via os.replace — readers always see a complete document. Regression test fault-injects an interrupted write; fails against the old in-place write.
• The stdio routing tests stub run_auto_update (no PyPI call / config write leaking across tests), and all four transport tests assert result.exit_code == 0 so future pre-run failures surface the real error.

Verification

• uv run pytest tests — 2946 passed, 33 skipped
• uv run pytest test-int/cli — 69 passed
• Both regression tests proven to fail with their fix stashed and pass with it restored
• uv run ruff check . (changed files clean; pre-existing hermes findings untouched), uv run ruff format ., uv run ty check src tests test-int — clean

🤖 Generated with Claude Code

Fixes #940